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Virtual Resource Attribute Directory 

Field of the Invention 

This invention relates to computer security, and in particular a method of controlling 
access to files in a computer system. 

5 Background of the Invention 

Computer operating systems, such as Unix, MS DOS and Windows, typically organize 
files in a tree structure. These files are given attributes, which are stored along with the 
files in the directory structure. Such attributes can include security controls determining 
who is permitted to access the files. 

10 The tight binding of security attributes with the information that they secure found in 
traditional operating systems leads to a restrictive and inflexible security policy 
implementation that varies from operating system to operating system. As a result, 
especially in networks running multiple operating systems, this inflexibility makes it 
difficult to permit central administration of security policy within a system. 

15 Summary of the Invention 

According to the present invention there is provided a method of controlling access to 
computer data, comprising the steps of: 

creating a real file system in a computer for storing said data; 

creating a virtual file system that mirrors said real file system but lacks the stored 
20 data; and 

storing attributes pertaining to the files in said file system at corresponding 
locations in said virtual file system. 

Typically the attributes contain security information determining who is permitted access 
to the files. The virtual file system is known as a virtual resource attribute directory. 

25 The essence of the invention is that it abstracts security away from the simple, fixed 
attributes that are available within particular operating systems.. The invention ensures 
that enterprise security policies are defined outside of the operating system, are 
administered centrally and applied to a single type of structure, the entity. This uniformity 
ensures policy coherence within an enterprise. 
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In another aspect the invention provides a virtual resource attribute directory comprising a 
shadow directory structure mirroring a real file structure and storing attributes of files in 
said real file structure without the associated data. 

The Virtual Resource Attribute Directory (VRAD) defines the structure of the virtualized 
5 elements of the information being protected. The principal function of the VRAD is to 
mediate access to information elements. The VRAD provides a mechanism to ensure that 
the security attributes required for proper functioning of a security system exist and are 
accessible. The VRAD is unique for a variety of reasons: 

• Non-intrusive to the virtualized system 

1 0 • Full mapping of extant security controls to security attributes 

• Additional security attributes per entity protected for fully realizable security 
policies 

• Portable, non-system dependent 

• Extensible and user configurable 

15 • Easily manipulatable 

The Virtual Resource Attribute Directory manages the security of information elements 
stored within it. The VRAD is thus a shadow of the real file system. For example, if the 
file system is a UNIX file system, then the VRAD would be a virtualization of the UNDC 
file system. At no point are the actual files modified in any way. No information is stored 
20 on the virtualized system other than that associated with the operational agents. There is a 
clear separation of security and information in a VRAD-managed system. The importance 
of the security features built into the operating system is significantly diminished. 

Brief Description of the Drawings 

The invention will now be described in more detail, by way of example only, with 
25 reference to the accompanying drawings, in which;- 

Figure 1 is an example showing linked security servers; and 

Figure 2 is an example showing cross linking of VRAD file systems. 
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Detailed Description of the Invention 

Referring to Figure 1, it will be seen that the Virtual Resource Attribute Directory 
(VRAD) 10, typically stored on a hard disk, resembles a rooted tree structure 12. This tree 
structure 12 represents the parent-child relationships that are found in the directory 
5 structures of all important file systems. The root 14 of a VRAD can be a security server 
also known as a generic policy engine, which controls all aspects of security on a 
network. AH elements in the VRAD are represented by entities and proxy entities. 

All the VRADs 10 are connected by a super-tree which has at its terminals the VRADs of 
the virtualized systems as shown in Figure 2. 

10 The various VRADs need not be from the same type of operating system. The VRAD is 
utilized to create a homogenous representation of all the information that resides within a 
security controlled realm. This includes unified user and group lists to assist in single 
sign-on and Authentication Server services. 

There remains, at all times, a one-to-one mapping between the physical machine with the 
15 resources being protected and a VRAD with the associated security attributes. The two 
are updated synchronously, via the use of agents, a security server, and message protocol 
to ensure that each remains perfectly synchronized. 

The VRAD 10 stores entities. An entity is the data structure that forms the starting point 
for all security-related activities. As such, it describes a minimal set of properties that are 

20 considered essential for effective security while being fully extensible. Every entity in a 
VRAD has a unique key generated without relation to the information that it represents; 
i.e., nothing concerning the data can be inferred from a knowledge of the information and 
vice versa. The unique key associated with an entity is called the entity identifier, or eid. 
The eid is represented using a number of bits, n, making the maximum size of the realm 

25 2° entities. The entity has a security policy associated with it, the security policy being 
represented by a name in order that policies may be shared by multiple entities in the 
VRAD. The actual policy is stored in a private part of the VRAD that may only be 
accessed by security officers. 

The attributes that are part of the entity are name, owner, data type, creation timestamp, 
30 last modified timestamp and last access timestamp and security policy. The data type 
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attribute points at a data structure that stores attributes particular to the name of the 
resource that the entity represents. For example, an entity representing a machine would 
have the data type machine-ID. A machine-ID instance would store the location of the 
machine, its IP address, and operating system type. 

5 Another type of data structure stored in a VRAD is a proxy entity. This provides a 
reference to an entity or another proxy entity that is managed outside of the realm in 
which the proxy is defined. The function of a proxy entity is to allow a security server to 
have access to entities outside of the realm without being responsible for their 
management and to remove the need for the generation of globally-unique entity 

10 identifiers across all realms within the enterprise. A proxy entity has a unique key (eid) 
similar to an entity and a URL that stores the location of the VRAD where the actual 
entity is stored. The URL consists of two pieces of information. First, the protocol, host 
and port for a remote security server is present. Second, the eid in the remote VRAD is 
present A proxy entity can be thought of as a "pointer" to the actual entity. It should be 

15 noted that eids are unique within the realm, i.e., no two entities, proxy entities or an entity 
and a proxy entity can have the same eid. 

When information on the actual entity is required, the GPE server managing the realm in 
which the entity is actually stored is contacted and the information retrieved using the 
InterRealm Security Protocol (IRSP). 

20 All relationships between entities are stored in a single data structure known as the Entity 
Relationship (ER) data structure. A one-to-one relation between two entities is stored as a 
single instance of an ER data structure. A one-to-many, many-to-one or many-to-many 
relationship is represented as several instances of ER data structures. The ER data 
structure stores the two entities involved in a relationship, the name of the relationship 

25 and a qualifying operator. For example, an ER data structure can be used to store the 

relationships, "A may read B" and "A may not read B." The difference in representation 
between the examples in the previous sentence in the value of the associated ER operator. 
Relationship data structures are used in policies associated with entities to respond to 
requests for access to an entity. The parent-child relationships that define the structure of 

30 a VRAD are stored using ER data structures. 
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A combination of one or more VRADs is called a Realm. A Realm contains all resources 
being protected, all users allowed access to those resources, all groups with which those 
users can be associated, and all physical machines (and their addresses) that represent the 
Realm. A realm defines a default security policy that is used when individual entities do 
5 not have a policy defined for them. This policy ensures that requests for access to 
resources will always be resolved. 

Realms may act as containers for other realms managed by other security servers. The 
enterprise realm is special in that it acts as a container for all other realms in the 
enterprise. If an entity is stored within a particular realm, its security is managed by that 
10 realm. 

Each entity stored within the VRAD has additional attributes and relationships to other 
entities associated with it. These include unique name, Entity ID, mandatory controls, etc. 
An entity includes a reference to another data structure by name that contains non-security 
specific information. For example, the physical location of a machine might be stored and 
15 used in a mediation function to prevent information legal in one country from being 
transmitted to a country in which that information is illegal. 

Since the structure is tree-like, it is easy to manipulate the structure via security 
messaging protocol designed to assist in walking a tree-like structure, and performing 
actions against it. Any tree-traversal algorithms can be utilized to manipulate the 
20 information stored within a VRAD. 

VRAD trees can be linked across security servers in order to provide a security solution 
across an enterprise. The proxy entity concept is used to achieve this. 

VRAD trees contain only entity or proxy entity data structures. The VRADs for the 
resources associated with each machine are stored as subtrees within the VRAD for the 

25 realm. The root of this tree is always an entity representing the GPE itself. This entity is 
called the realm root. The parent of the realm root is a proxy entity that represents the 
realm root, which is one level up in the enterprise security hierarchy. In the case of the 
enterprise realm root, it is its own parent It is possible to walk to any realm in the 
enterprise by walking to the parent of the realm root given appropriate security 

30 permissions. 
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When the parent of the realm root is requested, the proxy entity for the parent is retrieved. 
The IRSP is used to retrieve the eid of the remote entity if the requesting user has 
permission to do so. Referring to Figure 2, two realms 10„ 10 2 are represented. Realms 
10, and 10 2 are managed by GPE, and GPEj respectively. When an agent walks from 
5 Machine, to Files,, GPE, (realm root), then to the parent GPE (realm root of a parent 
realm), and finally to Users 2 on the remote GPE, the eid of UserSj under GPE 2 is returned. 
This eid is served up to the user and a new proxy created within realm,. Garbage 
collection of this proxy entity occurs when the user no longer needs to access the remote 
entity. 

10 WTiile the above example has demonstrated linking of realms through the realm root 
entity, cross linking of VRADs at other points within the realm is possible. For example, 
in Figure 2, a child directory of machine, in realm 2 is managed by realm,. A proxy for 
dir^ is maintained in realm 2 and a proxy for the root directory of machine, is stored in 
realm,. Walking from the root directory of machine, takes the user to dir^ in realm,. 

15 Walking to the children of dir n causes proxy entities to be generated in realm 2 that are 
removed when the user tells the system that they may be discarded or when the user logs 
out from the system. 

The invention provides a flexible approach to file security that is consistent across 
different operating systems. 
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We claim: 

1 . A method of controlling access to computer data, comprising the steps of: 
creating a real file system for storing said data; 

creating a virtual file system that mirrors said real file system but lacks the stored 
5 data; and 

storing attributes pertaining to the files in said file system at corresponding 
locations in said virtual file system. 

2. A method as claimed in claim 1 , wherein said attributes are security attributes. 

3. A method as claimed in claim 2, wherein said virtual file system manages the 
10 security attributes stored within it. 

4. A method as claimed in claim 3, wherein said virtual file system mediates access 
to said computer data in said real file system based on said stored attributes in said virtual 
file system. 

5. A method as claimed in claim 4, wherein said virtual file system is organized in a 
15 tree structure representing parent-child relationships found in said real file system. 

6. A method as claimed in claim 5, wherein said attributes are stored as entities 
describing the security properties of a corresponding file in said real file structure. 

7. A method as claimed in claim 6, wherein each said entity has a unique key 
generated without relation to the data whose attributes it describes. 

20 8. A method as claimed in claim 7, wherein each said key has a security policy 

associated with it to permit policies to be shared by multiple entities within the virtual file 
system. 

9. A method as claimed in claim 7, wherein each said entity stores the following 
attributes: name, owner, data type, creation timestamp, last modified timestamp, last 

25 access timestamp, and security policy. 

10. A method as claimed in claim 7, wherein said virtual file system also stores proxy 
entities referencing an actual entity stored in a different virtual file system to permit 
access to entities stored in said different virtual file system without requiring said first 
mentioned file system to be responsible for its management. 
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11. A method as claimed in claim 7, wherein all relationships between entities are 
stored in a single entity data structure. 

12. A method as claimed in claim 7, wherein a plurality of said virtual file systems are 
linked through their roots. 

5 13. A method as claimed in claim 7, wherein a plurality of said virtual file systems are 
cross linked at points on the tree structure. 

14. A virtual resource attribute directory comprising a shadow directory structure 
mirroring a real file structure and storing attributes of files in said real file structure 
without the associated data. 

10 15. A virtual resource attribute directory as claimed in claim 14, wherein said shadow 
directory structure is a tree structure. 

1 6. A virtual resource attribute directory as claimed in claim 14, wherein said 
attributes are stored as entities describing the security properties of a corresponding file in 
said real file structure. 

15 17. A virtual resource attribute directory as claimed in claim 1 6, wherein each said 
entity has a unique key generated without relation to the information whose attributes it 
describes. 
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